圖片來源：OpenTelemetry

OpenTelemetry Collector 是一個不受特定廠商限制的 Agent，用於收集與處理 Telemetry Data。它可以接收不同格式的 Telemetry Data（Traces、Metics、Logs），再將它們匯出到不同的後端。雖然直接把資料送往特定的後端，如 Tempo 或 Jaeger，可能看似沒有問題，但這樣的架構會使生成的資訊依賴於特定的後端。例如，後端出現問題或需要更換時，就必須要修改程式的設定檔，或者需要對資料進行額外的處理時，也必須要修改程式碼才能達成。

引入 Collector 之後，就達到了依賴反轉的效果。Collector 作為一個介面，位於服務與後端之間，讓服務只需將資料送往 Collector。Collector 會處理資料後再送往後端，達到解耦的效果。此外，Collector 提供了多種的 Processor，能進行資料轉換、過濾、抽樣等處理，這些都透過設定檔來完成，無需修改程式碼或重啟服務，實現了動態調整的功能。

OpenTelemetry Collector 有 Core 和 Contrib 兩個版本。Core 版本只提供最基本的功能，而 Contrib 版本則包含了各種額外的元件。例如，Routing Connector 可以依條件分派資料流向，而 Kafka Receiver 則可以從 Kafka 取得資料，這些都是在 Contrib 才提供的元件。所以在使用時，需注意所需的功能是否包含在 Core 版本內。如果不包含，則需要使用 Contrib 版本。

Concepts

Deployment

Collector 主要可以分為三種部署方式，在官網中有介紹了各種部署方式的優缺點，詳細可以參考 Deployment。以下為簡單的整理與介紹：

圖片來源：OpenTelemetry

1. No Agent：直接將資料送往 Backend，不使用 Collector
   1. 優點：簡單、快速，架構單純。
   2. 缺點：服務與 Backend 之間耦合度高，若需調整資料處理方式，必須修改程式碼。
2. Agent：將資料送往 Collector，Collector 再將資料送往 Backend
   1. 優點：能對資料進行額外處理，降低服務與 Backend 之間的耦合度，且不需修改程式碼。
   2. 缺點：增加了一個 Agent，提高了架構複雜度，服務擴展時也需考慮 Agent 的擴展。
3. Gateway：將資料送往一個統一的 Gateway Collector，該 Gateway Collector 依規則分流至不同的 Collector，Collector 再將資料送往 Backend
   1. 優點：達成專注點分離，如同單體架構轉為微服務架構，不同的 Collector 可專注於不同功能，提高架構彈性。
   2. 缺點：增加了 Gateway Collector 和多個不同的 Collector，使得架構更為複雜。

增加 Collector 雖能大幅提升整體架構的彈性，但同時也提高了維運的複雜度與成本。因此，也需增加對應的監控與備援機制，以防 Collector 成為架構中的瓶頸或單點失敗點。

Configuration

OpenTelemetry Collector 的設定檔採用 YAML 格式，主要用於定義資料的處理流程（pipeline）以及 Collector 的設定。設定檔大致可分為兩大類：

1. 用於宣告元件設定的 Section：包括 receivers、processors、exporters、connectors 和 extensions。這些用於宣告元件與參數，需要透過 service Section 來啟用。
   1. Section 中的 Key 值即為該元件的類型，若有相同類型的元件，則可以在 Key 值後面加上 /[name] 來區分，例如：otlp/trace、otlp/metrics 都是使用 otlp 這個類型的元件，但有不同的名字。
   2. 若設定中只有 Key，則表示該元件參數全部採用預設值。
   3. 元件的資訊可以在 opentelemetry-collector 跟 opentelemetry-collector-contrib 兩個 Repository 中找到。元件 Readme 的 Distributions 若有標記 core 表示在 Core 版本中可以直接使用，若只有標記 contrib 則必須使用 Contrib 版本才能使用。
2. 用於 Collector 設定的 Section：service，主要定義 Collector 的設定以及要執行的 pipeline。

在設定檔中的樣式與詳細說明如下：

receivers:
  # 宣告資料的來源元件，例如：接收 OTLP 格式的資料
  otlp:
    protocols:
      grpc:
      http:

processors:
  # 宣告資料的處理元件，例如：過濾符合條件的資料
  batch:

exporters:
  # 宣告資料的輸出元件，例如：將資料輸出至 Tempo
  otlp:
    endpoint: otelcol:4317

connectors:
  # 宣告資料的連接元件，它可以同時作為一個 Pipeline 的輸出與另一個 Pipeline 的來源，例如：將 A Pipeline 輸出的資料轉發至另一個 B Pipeline 的來源
  forward:

extensions:
  # 宣告有哪些 Collector 本身可以用的 Extension，與 Pipeline 無關，例如：Collector 的 health_check
  health_check:
  pprof:
  zpages:

service:
  # 實際定義 Collector 要啟用哪些功能以及 Pipeline 的 Section
  pipelines:
    # 透過前面定義的元件建立的 Pipeline
    traces: # 定義一個名為 traces 的 Pipeline，會從 receivers 接收資料後，經過 processors 處理，再輸出至 exporters
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
  telemetry:
    # Collector 本身要揭露的 Telemetry Data
    metrics: # 揭露 Collector 的 Metrics 在 8888 Port
      level: detailed
      address: 0.0.0.0:8888
  extensions:
    # 引用前面宣告的 Extension，讓 Extension 實際生效
    - health_check
    - pprof
    - zpages

Receiver

既然都是 OpenTelemetry Collector，最常用的輸入資料格式即是 OTLP。OTLP Receiver 能夠接收 OTLP 格式的 Traces、Metrics 和 Logs。透過設定，可以開啟不同的 Protocol 來接收資料，如：gRPC、HTTP。

receivers:
  otlp:
    protocols:
      grpc: # 開啟 gRPC 預設為 0.0.0.0:4317
      http: # 開啟 HTTP 預設為 0.0.0.0:4318

針對不同 Protocol 有其他詳細的設定，例如 CORS、TLS，可以參考官方的 Advanced Configuration。

Exporter

Collector 支援多種輸出方式，例如，透過 gRPC 以 OTLP 格式輸出至 Tempo 或 Jaeger 的 OTLP gRPC Exporter。

exporters:
  otlp:
    endpoint: tempo:4317
    tls:
      insecure: true
  otlp/jaeger:
    endpoint: jaeger-collector:4317
    tls:
      insecure: true

可以看到，這裡宣告了兩個 OTLP Exporter：一個是輸出至 Tempo，另一個是輸出至 Jaeger。第一個直接命名為 otlp，第二個則是命名為 otlp/jaeger。如此便可區分不同的 Exporter，儘管它們實際上都使用了 otlp 這個類型的 Exporter。

Processor

在 Receiver 接收資料後，可以透過 Processor 進行加工，然後再透過 Exporter 進行輸出。加工的方式有多種，如過濾、轉換和抽樣等，詳細可以參考官方的 Processors。其中，官方強烈建議要啟用的是 Batch Processor：

processors:
  batch:

Batch Processor 會先暫存收到的資料，當資料量達到一定數量或時間時，才會進行一次性的處理。這樣做可以減少資料傳輸次數，從而提高效能。

Service

Service Section 是用於實際定義 Collector 行為的部分，主要包含 pipelines、extensions 和 telemetry 三個部分。

Pipelines

首先來看 pipelines。前面提到的 receivers、processors 和 exporters 只是宣告我們預計要使用哪些元件，而真正的啟用和組合則是在 pipelines 中定義。例如，我們想要建立一個處理 Trace 的 Pipeline，它從 otlp Receiver 接收資料後，經過 batch Processor 處理，再輸出至 otlp Exporter：

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Pipeline 流程圖

通過上述設定，我們才實際建立了一個會被執行的資料處理流程。在每個 Pipeline 中的 receivers、processors、exporters 定義了要使用的元件，三者都可以同時使用多個元件，但要注意 processors 有多個時其順序會影響到資料的處理順序。

Pipeline 也有類型的區別，分為 traces、metrics、logs，分別對應處理不同類型的資料，這裡我們定義的是 traces，該 Pipeline 只會處理 Traces 資料。與元件一樣，Pipeline 也可以取名，一樣是在 Key 後面加上 /[name] 來區分，例如：traces/jaeger、traces/tempo，這樣就可以區分不同的 Pipeline。

Extensions

Extensions 主要用於啟用 Collector 本身的擴充功能，如 health_check、pprof 和 zpages 等。這些 Extensions 需要在 extensions Section 中先行宣告，然後再在 service Section 中啟用。例如：啟用 health_check Extension：

service:
  extensions:
    - health_check

完整的 Extensions 清單可參考 Core Repo 的 extension 與 Contrib Repo 的 extension。

Telemetry

為了監控和確保 Collector 服務運行正常，Collector 可以揭露其自身的 Telemetry Data，以供外部服務監控。目前可以提供 Logs 與 Traces 兩種資訊，例如揭露 Metrics：

service:
  telemetry:
    metrics:
      level: detailed
      address: 0.0.0.0:8888

Connector

瞭解了 Pipeline 之後，我們來看看 Connector。Connector 可以作為一個 Pipeline 的輸出，再成為另一個 Pipeline 的輸入，它就像是不同 Pipeline 之間的橋樑。例如，Forward Connector 可以達成轉到轉發跟匯流的效果：

receivers:
  foo/blue:
  foo/green:
processors:
  attributes/blue:
  attributes/green:
  batch:
exporters:
  bar:
connectors:
  forward:
service:
  pipelines:
    logs/blue:
      receivers: [foo/blue]
      processors: [attributes/blue]
      exporters: [forward]
    logs/green:
      receivers: [foo/green]
      processors: [attributes/green]
      exporters: [forward]
    logs:
      receivers: [forward]
      processors: [batch]
      exporters: [bar]

Pipeline 流程圖

完整的 Connector 清單可參考 Core Repo 的 connector 與 Contrib Repo 的 connector。

Lab

範例程式碼：22-otel-collector

Quick Start

1. 啟動所有服務

   docker-compose up -d
   

2. 檢視服務

   1. FastAPI App

      1. app-a: http://localhost:8000
      2. app-b: http://localhost:8001
      3. app-c: http://localhost:8002

   2. Grafana: http://localhost:3000，登入帳號密碼為 admin/admin

      1. 點擊左上 Menu > Explore，左上 Data Source 選擇 Tempo，即可看到 Traces 資料

      2. 透過瀏覽器對 application 的 /chain 發送 Request，可以在 Trace 資訊中看到 app-a、app-b、app-c 互相呼叫的順序

         1. app-a: http://localhost:8000/chain
         2. app-b: http://localhost:8001/chain
         3. app-c: http://localhost:8002/chain

      3. 或是使用 k6 發送 Request

         k6 run --vus 1 --duration 300s k6-script.js
         

   3. Prometheus: http://localhost:9090

      1. 搜尋 {job="otel-collector"} ，可以看到 OpenTelemetry Collector 揭露的 Metrics

3. 關閉所有服務

   docker-compose down
   

Goals

1. 建立 FastAPI App（app-a、app-b、app-c），透過 OpenTelemetry Automatic Instrumentation 產生與收集 Traces，並發送至 OpenTelemetry Collector
2. 建立 OpenTelemetry Collector
   1. 接收 Traces 資料，經過處理後發送至 Tempo
   2. 揭露 OpenTelemetry Collector 的 Metrics 在 8888 port，供 Prometheus 收集
3. 建立 Tempo，接收 Traces 資料
4. 建立 Prometheus，收集 OpenTelemetry Collector 的 Metrics
5. 建立 Grafana，查詢 Tempo 顯示 Traces 資料

小結

從上文我們可以明顯看出，OpenTelemetry Collector 在架構設計上與之前介紹過的 Fluent Bit 和 Vector 高度相似。它們基本上都遵循 「Input -> Processor -> Output」 的工作流程，因為本質上，這些工具都是擔任 Pipeline 的角色。雖然各家都開始著重於能同時處理 Metrics、Traces 和 Logs，但各自仍有其專精領域。像 OpenTelemetry Collector 在 Trace 的處理上是最強的，而且其 Input 主要以 OTLP 為主。相對地，Fluent Bit 和 Vector 則支援更多不同類型的 Input，並且偏向於處理 Log。

目前選擇這類工具時，建議還是要盡可能選擇各自專精的領域，因為多數工具在非專精領域的功能大多還在 Beta 階段。等這些工具日後成熟，可以再考慮是否需要切換統一使用一個，比較理想的方式是，優先選擇使用主流的格式，例如 OTLP 和 Prometheus。這樣在未來即使要更換工具，也不必擔心沒有合適的 Input 和 Output。

至此我們以經介紹完 Metrics、Logs、Traces 的生成、收集、儲存、使用四個階段，接下來我們將進入應用篇，介紹如何搭配使用這些 Observability Signals 發揮出綜效。

參考資料

1. OpenTelemetry Collector
2. Difference between OpenTelemetry Collector and OpenTelemetry Collector Contrib
3. What are Connectors in OpenTelemetry?